Runtime model
Execution context and account state
Execution context is the information that surrounds a strategy revision when Structure evaluates it. It explains which account or simulated account is being used, what position state is available, which venue and instrument the revision belongs to, and which execution destination receives order activity.
This context matters because the same strategy revision can behave differently under different Strategy Variable values, account state, simulator assumptions, or live venue constraints.
What execution context includes
Section titled “What execution context includes”Execution context can include:
- Selected strategy and revision.
- Strategy Variable values.
- Revision-owned venue and instrument.
- Connected account for a live deployment.
- Simulated account state for a paper deployment or backtest job.
- Current positions and target exposure.
- Balances and margin context where available.
- Venue permissions.
- Execution destination.
- Fees, slippage, latency, and simulator assumptions for simulated paths.
- Logs, health state, and telemetry surfaced by the app.
The exact fields vary by path and venue. The purpose is consistent: keep strategy logic, run settings, account state, and execution destination visible enough to interpret behavior.
- Target Position Executor Target-position intent converted into order activity.
- Live exchange gateway Venue-facing live order message boundary.
- Venue Simulator Simulated execution destination and assumptions.
- Account state Live or simulated positions, fills, balances, and order state.
- Run settings Run-provided values, balances, ranges, or assumptions.
- Target positions Desired exposure emitted by strategy evaluation.
Connected account boundary
Section titled “Connected account boundary”A live deployment requires a connected venue account with the permissions needed for execution. Structure is launching first with Hyperliquid, and supported venue setup steps belong in the account connection flow.
A connected account authorizes Structure only for that specific venue account. It does not grant Structure access to unrelated wallets, exchange accounts, venues, withdrawals, or transfers.
After venue access is removed or an account is disconnected in Structure, any live deployment using that account no longer has venue authorization for it.
Account position state
Section titled “Account position state”Account position state is the latest available information Structure can surface about the account or simulated account.
Conceptually, account state can include:
- Positions by instrument.
- Balances by asset.
- Margin context where available.
- Open order state where available.
- Fill activity where available.
- Health signals where available.
Account state helps users compare current exposure with target exposure. It also helps users understand whether a live deployment, paper deployment, or backtest job is behaving as expected.
Live venue constraints
Section titled “Live venue constraints”Live deployments operate through the connected venue account and live exchange gateway.
Live behavior can be affected by:
- Venue permissions.
- Available balances and margin.
- Existing account positions.
- Supported instruments.
- Venue order state.
- Fills, cancellations, rejections, or errors.
- Venue-specific connection health.
- Market conditions and liquidity.
These constraints are part of live operation. They are one reason backtest jobs and paper deployments are evidence under assumptions, not guarantees of live execution quality.
Simulated account state
Section titled “Simulated account state”Paper deployments and backtest jobs use simulated account state through the Venue Simulator.
Simulated account state can include starting balances, simulated positions, simulated fills, and simulated order state under the selected assumptions. It is useful for evaluation, but it is not the same as a live venue account.
The Venue Simulator does not model the full exchange order book. Review fees, slippage, latency, liquidity assumptions, fill model, and data completeness when interpreting simulated results.
Monitoring boundaries
Section titled “Monitoring boundaries”Monitoring views help users review:
- Deployment or job status.
- Selected revision.
- Strategy Variable values.
- Current target exposure.
- Account or simulated account state.
- PnL where available.
- Order activity and fills where available.
- Logs, errors, and health signals.
Monitoring does not remove user responsibility for trading decisions, capital allocation, account permissions, or venue-level risk management.
Practical takeaway
Section titled “Practical takeaway”Execution context explains the conditions under which a revision is evaluated. When comparing behavior across live deployments, paper deployments, and backtest jobs, keep the selected revision, Strategy Variable values, account state, execution destination, and assumptions attached to the result.